Remarks 



I. 35 U.S.C. §101 

The Office Action rejects claims 22 and 23 under 35 U.S.C. §101 as allegedly 
being directed to non-statutory subject matter. Applicants respectfully disagree with this 
rejection but have nevertheless amended claims 22 and 23 to recite that the computer 
readable medium is "non-transitory." 

Applicants also note that the law regarding § 101 has fluctuated significantly in 
recent years, and applicants reserve the right to delete the "non-transitory" limitation 
should the law change again. 

II. 35 USC §103 - Kerr in view of Willkie 

The Office Action rejects claims 1-13, 17-22 and 24-27 under 35 USC §103(a) as 
allegedly being unpatentable over U.S. Patent No. 6,243,667 to Kerr et al. ("Kerr") in 
view of U.S. Patent No. 6,682,851 to Willkie et al. ("Willkie"). 

A. Claim 1 

Regarding claim 1, the Office Action states: 

Regarding Claim 1 Kerr et al. discloses a method of identifying 
multiple packets in a communication flow between a source entity and a 
destination entity, comprising (see figure 2, message flow patterns): 

storing, in a network interface for the destination entity, a first flow 
identifier of a first packet received from a source entity for a destination 
entity, wherein said first flow identifier comprises an identifier of the 
source entity and an identifier of the destination entity (see col. 3, lines 57- 
67, flow identifying, identifying a flow for the packet, see col. 6, lines 29- 

41, the flow cache, stores the flow identifiers, including the source and the 
destination, see col. 1, lines 62-66, the collected information is reported to 
devices on the network( reads on network interface devices for the 
destination entity as broadly claimed), see also figure 1, section 540 
reporting device); 

storing, in the network interface said first packet in a packet 
memory for transfer toward the destination entity; storing, in said network 
interface a second flow identifier of a second packet( see col. 6, lines 32- 

42, flow cache( memory), stores the flow identifiers, see col. 3, lines 56- 
67, the router stores the packet for transfer to the destination); 

storing in said network interface said second packet in said packet 
memory; determining whether said first flow identifier matches said 
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second flow identified see col. 3, lines 55-67, the router stores packets, 
and identifies the message flow using the flow identifier of the header); 

storing a first indicator in the destination entity if a first 
communication flow identified by said first flow identifier comprises said 
second packet;( see col. 7, lines 56-57, collecting and reporting 
information about messages flow, reporting reads on a indicator), see col. 
8, lines 35- 56, the routing device transmits the information packet about 
message flows( including the flow identified) to a destination device, see 
col. 4, lines 1-7, the routing device look up the flow cache to determine a 
flow, results are identified or new) and 

storing a second indicator in the destination entity if said first 
packet is the only packet stored in the packet memory that is part of said 
first communication flow( see col. 7, lines 56-57, collecting and reporting 
information about messages flow, reporting reads on a indicator), see col. 
8, lines 35-56, the routing device transmits the information packet about 
message flows( including when the flow identified includes only one 
packet) to a destination device, see col. 4, lines 1-7, the flow is identified 
as new if the first packet only packet part of the communication flow). 

Kerr et al. fail to explicitly state storing a first indicator in the 
destination entity, and storing a second indicator in the destination entity 
as claimed. 

However Willikie et al. teaches storing a first indicator in the 
destination entity, and storing a second indicator in the destination entity 
(see col. 3, lines 45-65, Willikie et al. teaches a QMIP unit which receives 
and stores data from a set of modules, which comprises a memory which 
stores a received flow control indication from each module, the flow 
indicator indicates if transmission of data is to cease , the QMIP creates a 
frame which carries data information and flow control indication , the 
QMEP forward frame over the common data link). 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Willikie et al. invention because Willikie et al. transfers data between 
multiple entities over a serial link in a efficient manner( see Willikie et al. 
see col. 3, lines 38-41) 

Applicants respectfully disagree with this rejection. As noted applicants' prior 
response, Kerr teaches a router that does not store, in a network interface for the 
destination entity, a first flow identifier. Willkie teaches a wireless communication 
system that also does not store, in a network interface for the destination entity, a first 
flow identifier. Applicants respectfully assert that one of ordinary skill in the art would 
not have arrived at this limitation if presented with Kerr in view of Willkie. 

Nevertheless, applicants have amended claim 1 to focus on another aspect of the 
invention. In particular, applicants have added the limitation of "decoding, by said 
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network interface, a header of the first packet to determine a length of data to be stored in 
said destination entity, wherein said header conforms to a protocol above TCP." 

Support for this limitation can be found, for instance, at page 1 6, lines 15-18 and 
page 25, lines 10-13 of the present application. 

Applicants respectfully assert that neither Kerr nor Willkie teaches or suggests 
this limitation. For these reasons applicants respectfully assert that claims 1 and 2 are 
nonobvious over Kerr in view of Willkie. 



B. Claims 3 and 22 

Regarding claims 3 and 22, the Office Action states: 

Regarding Claims 3 and 22 Kerr et al. discloses a method of 
identifying one or more packets in a communication flow between a 
source entity and a destination entity, comprising: 

receiving a first packet at a communication device that is a 
network interface for a host computer ( see col. 3, lines 55-56, receives a 
packet, see figure 1, section 140, routing device); 

identifying by said network interface a first communication flow 
comprising said first packet with a first flow identifier configured to 
identify both the source entity and the destination entity(see col. 3, lines 
57-67, flow identifying, identifying a flow for the packet, see col. 6, lines 
29-41, the flow cache, stores the flow identifiers, including the source and 
the destination); 

determining by said network interface whether said first 
communication flow also comprises a second packet received at said 
communication device after said first packet was received at said 
communication device( see col. 3, lines 49-67, the router determines the 
message flow of the received packets); and 

transferring said first packet to a host computer for processing in 
accordance with a communication protocol associated with said first 
packet (see col. 8, lines 35-59, the router build an information packet 
which is then sent to a destination device (host computer), in accordance 
to a communication protocol, for processing, see col. 2-3, lines 50-2, the 
router, processes in accordance to a transmission protocol type of the first 
packet). 

Kerr et al. fail to explicitly point out transferring said first packet 
to a host computer as claimed. 

However Willikie et al. teaches transferring said first packet to a 
host computer (see col. 3, lines 60-65, the QMIP unit creates a frame 
which carries data information and flow control information and forwards 
the frame over the common data link to a host computer( entity) ). 
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Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Willikie et al. invention because Willikie et al. transfers data between 
multiple entities over a serial link in a efficient manner( see Willikie et al. 
see col. 3, lines 38-41). 

Applicants have amended claim 3 to recite, in part, "decoding, by said network 
interface, a header of the first packet to determine a length of data to be stored in the 
destination entity, wherein said header conforms to a protocol above TCP." Applicants 
have also amended claim 3 to recite, in part, "transferring said header of said first packet 
to said host computer for processing said data." 

Support for these limitations can be found, for instance, at page 16, lines 15-18 
and page 25, lines 10-13 of the present application. 

Applicants respectfully assert that neither Kerr nor Willkie teaches or suggests 
this limitation. For these reasons applicants respectfully assert that claims 1 and 2 are 
nonobvious over Kerr in view of Willkie. 

Applicants have similarly amended claim 22 to recite, in part, "decoding, by said 
network interface, a header of the first packet to determine a length of data to be stored in 
the destination entity, wherein said header conforms to a protocol above TCP." 

Applicants respectfully assert that neither Kerr nor Willkie teaches or suggests 
this limitation. For these reasons applicants respectfully assert that claim 22 is 
nonobvious over Kerr in view of Willkie. 

C. Claims 2 and 24 

Regarding claims 2 and 24, the Office Action states: 

Regarding Claims 2 and 24 Kerr et al. discloses everything as 
applied above (see claims 1 and 3). 

prior to said storing a first flow identifier, parsing said first packet 
to retrieve said identifier of the source entity and said identifier of the 
destination entity( see col. 3, lines 56-67, the routing device examines a 
header for the packet, to retrieve identifiers). 

Claim 2 depends from claim 1 and claim 24 depends from claim 3, which are 
nonobvious over Kerr in view of Willkie, as discussed above, and so claims 2 and 24 are 
also nonobvious. 
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D. Claim 4 



Regarding claim 4, the Office Action states: 

Regarding Claim 4 Kerr et al. discloses everything as applied 
above (see claim 3). 

transferring said second packet to said host computer( see col. 3, 
lines 55-56, the router receive packet, by definition the router receives 
packet than forwards the packet to destination); 

wherein said host computer is configured to collectively process a 
header portion of said first packet and a header portion of said second 
packet in accordance with said communication protocol (see col. 2-3, lines 
50-2, the router, processes in accordance to a transmission protocol type of 
the first packet, see col. 3, lines 57-67, the header is examined, the 
destination device (host computer) will process the packet likewise). 

Claim 4 depends from claim 3, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 4 is also nonobvious. 



E. Claims 5 and 18 

Regarding claims 5 and 18, the Office Action states: 

Regarding Claims 5 and 18 Kerr et al. discloses everything as 
applied above (see claims 3 and 16). 

wherein said identifying comprises: 

receiving a flow key generated by concatenating an identifier of 
the source entity and an identifier of the destination entity( see col. 6, lines 
32-41, the flow keys , with information about message flows to include the 
source and the destination flow identifiers); 

wherein said first flow identifier comprises said flow key( see col. 
6, lines 32-41, the flow cache includes the flow keys about the messages 
flows). 

Claim 5 depends from claim 3, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 5 is also nonobvious. Claim 16 was not actually 
rejected above, but as discussed below, claim 16 has been amended to recite, in part, 
"decoding the header by the network interface to determine a length of data, wherein said 
header conforms to a protocol above TCP." As noted below, claim 16 is nonobvious 
over Kerr in view of U.S. Patent No. 5,819,1 1 1 to Davies et al. ("Davies"). Claim 1 8 
depends from claim 16 and so is also nonobvious. 
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F. Claims 6 and 17 



Regarding claims 6 and 17, the Office Action states: 

Regarding Claims 6 and 17 Kerr et al. discloses everything as 
applied above (see claims 3 and 16). 

wherein said identifying comprises: 

receiving an index of said first communication flow in a flow 
database; wherein said first flow identifier comprises said index( seel col. 
6, lines 31-49, the flow cache had a buckets of entries, of a database flow, 
which comprises a four-byte pointer( reads on index)). 

Claim 6 depends from claim 3, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 6 is also nonobvious. Claim 16 was not actually 
rejected above, but as discussed below, claim 16 has been amended and is nonobvious 
over Kerr in view of Davies. Claim 17 depends from claim 16 and so is also nonobvious. 



G. Claim 7 

Regarding claim 7, the Office Action states: 

Regarding Claim 7 Kerr et al. discloses everything as applied 
above (see claim 3). 

wherein said determining comprises comparing said first flow 
identifier with a second flow identifier associated with a second packet 
received at said communication device (see col. 4, lines 1-7, the routing 
device performs lookup in a flow cache comparing the flow identifiers 
with second packet to determine message flows). 

Claim 7 depends from claim 3, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 7 is also nonobvious. 

H. Claim 8 

Regarding claim 8, the Office Action states: 

Regarding Claim 8 Kerr et al. discloses everything as applied 
above (see claim 7). 

wherein said determining further comprises: 

storing said first flow identifier in a flow memory( see col. 6, lines 
29-50, the flow cache stores the flow identifiers in a flow memory) ; and 

storing said second flow identifier in said flow memory( see col. 6, 
lines 29-50, the second flow identifier is stored); and 
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comparing said stored first flow identifier and said stored second 
flow identified see col. 4, lines 1-7, the message flow is identified by 
comparing flow identifiers). 

Claim 8 depends from claim 7, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 8 is also nonobvious. 

I. Claim 9 

Regarding claim 9, the Office Action states: 

Regarding Claim 9 Kerr et al. discloses everything as applied 
above (see claim 8). 

wherein said flow memory is an associative memory in said 
communication device (see figure 3, section 300 flow caches). 

Claim 9 depends from claim 8, which is nonobvious over Kerr in view of Willkie, 
as discussed above, and so claim 9 is also nonobvious. 

J. Claim 10 

Regarding claim 10, the Office Action states: 

Regarding Claim 10 Kerr et al. discloses everything as applied 
above (see claim 3). 

storing said first packet in a packet memory (see col. 7, lines 59- 
61, collecting information about message flow patterns, to include, see col. 
8, lines 4-16, collecting ( storing) actual data, packets transmitted as part 
of the flow itself) see col. 2, lines 40-45, the router stores the packet in its 
memory). 

Claim 10 depends from claim 3, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 10 is also nonobvious. 



K. Claim 11 

Regarding claim 1 1, the Office Action states: 

Regarding Claim 11 Kerr et al. discloses everything as applied 
above (see claim 10). 

wherein said determining comprises comparing said first flow 
identifier configured to identify said first communication flow with a 
second flow identifier configured to identify a second communication 
flow comprising a packet stored in said packet memory (see col. 4, lines 1- 
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7, the message flow is identified by comparing flow identifiers, if new 
flow is determined or old message flow). 

Claim 1 1 depends from claim 10, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 1 1 is also nonobvious. 



L. Claims 20 and 27 

Regarding claims 20 and 27, the Office Action states: 

Regarding Claims 20 and 27 Kerr et al. discloses everything as 
applied above (see claims 16 and 3). 

storing a first indicator in a host memory if said communication 
flow comprises said second packet; and storing a second indicator in said 
host memory if said first packet is the only packet in said packet memory 
that is part of said communication flow (see col. 4, lines 1-7, the message 
flow is identified by comparing flow identifiers, if new flow is determined 
or old message flow). 

Claim 16 was not actually rejected above, but as discussed below, claim 16 is 
nonobvious over Kerr in view of Davies. Claim 20 depends from claim 16 and so is also 
nonobvious. Claim 27 depends from claim 3, which is nonobvious over Kerr in view of 
Willkie, as discussed above, and so claim 27 is also nonobvious. 



M. Claims 21. 25 and 26 

Regarding claims 21, 25 and 26, the Office Action states: 

Regarding Claims 21, 25 and 26 Kerr et al. discloses a 
communication interface, comprising: 

a header parser configured to parse a header of a first packet 
received at the communication interface, wherein the first packet was 
issued from a source entity for a destination entity ( see col. 3, lines 57-67, 
the router device examines the headers of the received packets packets, see 
figure 1, communication interface attached via a communication link); 

a flow database configured to facilitate management of a 
communication flow comprising the first packet, the flow database 
comprising( seel col. 6, lines 31-49, the flow cache had a buckets of 
entries, of a database flow, which comprises a four-byte pointer( reads on 
index)): 

a flow key configured to identify the communication flow using 
identifiers of the source entity and the destination entity( see col. 6, lines 
32-36, the flow cache, comprise a memory which associated flow keys 
which include the source and the destination); 
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an activity indicator configured to indicate a recency with which a 
packet in the communication flow has been received( see col. 5, lines 51- 
54, at step 241, the routing device examines, in the flow cache and 
compares the current time with the last time a packet was routed using a 
particular entry); and 

a validity indicator for indicating whether the communication flow 
is valid( see col. 3, lines 39-49, the routing device maintains the flow 
cache and remove message flow that are no longer valid. Indicating 
message flow is no longer valid); 

a code generator configured to generate an operation code for the 
first packet, to facilitate forwarding of the first packet toward the 
destination entity( see col. 6, lines 29-41, the flow cache has flow keys 
that reads on operation code, which includes information about a 
particular message flow); and 

a packet batching module configured to determine whether a 
second packet received at the communication interface is part of the 
communication flow( see col. 3-4, lines 57-7, the router device identifies a 
message flow by comparing received packets ). 

Applicants have amended claim 21 to recite, in part, "a processor for processing a 
header portion of said first packet and determining a length of data to be stored in the 
destination entity, wherein said header portion conforms to a protocol above 
Transmission Control Protocol (TCP)." Support for this limitation can be found, for 
instance, at page 16, lines 15-18 and page 25, lines 10-13 of the present application. 
Applicants respectfully assert that neither Kerr nor Willkie teaches or suggests this 
limitation. For these reasons applicants respectfully assert that claim 21 is nonobvious 
over Kerr in view of Willkie. 

Applicants have amended claim 25 to recite, in part, that "the header including a 
Transmission Control Protocol (TCP) header and a header above TCP that is decoded to 
determine a length of data being received." Support for this limitation can be found, for 
instance, at page 16, lines 15-18 and page 25, lines 10-13 of the present application. 
Applicants respectfully assert that neither Kerr nor Willkie teaches or suggests this 
limitation. For these reasons applicants respectfully assert that claim 25 is nonobvious 
over Kerr in view of Willkie. 

Applicants have amended claim 26 to similarly recite, in part, "decoding, by the 
communication interface, a second header portion of the first packet to determine a length 
of data being received, said second header portion conforming to a protocol above TCP." 
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Support for this limitation can be found, for instance, at page 16, lines 15-18 and page 25, 
lines 10-13 of the present application. Applicants respectfully assert that neither Kerr nor 
Willkie teaches or suggests this limitation. For these reasons applicants respectfully 
assert that claim 26 is nonobvious over Kerr in view of Willkie. 



III. 35 USC §103 - Kerr in view of Davies 

The Office Action rejects claims 14-16 and 23 under 35 USC § 103(a) as allegedly 
being unpatentable over Kerr in view of Davies. Claims 14 and 15 have been canceled. 

A. Claim 16 

Regarding claim 16, the Office Action states: 

Regarding Claim 16 Kerr et al. discloses a method of transferring 
a packet from a network interface to a host computer, comprising: 

receiving a first packet at a network interface( see col. 3, lines 55- 
56, receives a packet, see figure 1, section routing device); 

storing said first packet in a packet memory see col. 3, lines 55-67, 
the router stores packets) 

receiving a first flow identifier configured to identify a 
communication flow comprising said first packet(see col. 3, lines 57-67, 
flow identifying, identifying a flow for the packet, see col. 6, lines 29-41, 
the flow cache, stores the flow identifiers, including the source and the 
destination); 

storing said first flow identifier in a flow memory(see col. 6, lines 
29-41, the flow cache, stores the flow identifiers, including the source and 
the destination); 

searching said flow memory for a second packet in said 
communication flow received at the network interface after said first 
packet( see col. 3, lines 49-67, the router determines the message flow of 
the received packets); 

transferring header of said first packet to said host computer(see 
col. 8, lines 35-59, the router builds an information packet which is then 
sent to a destination device (host computer), in accordance to a 
communication protocol, for processing, see col. 2-3, lines 50-2, the 
router, processes in accordance to a transmission protocol type of the first 
packet); and 

Kerr et al. fails to specifically point out configuring an indicator in 
a host memory to indicate whether processing of said first packet by said 
host computer should be delayed to await transfer of said second packet to 
said host memory as claimed. 

Davies et al. teaches configuring an indicator in a host memory to 
indicate whether processing of said first packet by said host computer 
should be delayed to await transfer of said second packet to said host 
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, memory (See col 4, lines 8-13, The disabling step can include checking if 
a run length encoded data transfer is pending from the host, and if so, 
delaying disabling of the data transfers from the host to the peripheral until 
a data byte associated with the run length encoded data is received by the 
interface controller, otherwise do not delay). 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Davies et al. invention because Davies et al. invention provides 
provide methods and apparatus for reducing the complexity of 
programming on the peripheral side of an IEEE interface (see Davies et al. 
col. 3, lines 10-16) 

Applicants have amended claim 16 to recite, in part, "decoding the header by the 
network interface to determine a length of data, wherein said header conforms to a 
protocol above TCP." Support for this limitation can be found, for instance, at page 16, 
lines 15-18 and page 25, lines 10-13 of the present application. Applicants respectfully 
assert that neither Kerr nor Davies teaches or suggests this limitation. For these reasons 
applicants respectfully assert that claim 16 and all the claims that depend from claim 16 
are nonobvious over Kerr in view of Davies. 



B. Claim 23 

Regarding Claim 23 Kerr et al. discloses a processor readable 
storage medium containing a data structure configured to store 
information concerning a packet to be transferred from a network interface 
to a host computer, the data structure including one or more entries, each 
entry comprising: 

a flow number configured to identify a communication flow 
comprising a first packet received at the network interface from a source 
entity for a destination entity associated with the host computer( see col. 6, 
lines 29-41, the flow cache has flow keys that reads on flow number); and 

a validity indicator configured to provide( see col. 3, lines 39-49, 
the routing device maintains the flow cache and remove message flow that 
are no longer valid. Indicating message flow is no longer valid); 

wherein said data structure is searched for a second entry 
containing said flow number when said first packet is transferred to the 
host computer to determine if said communication flow also comprises a 
second packet received at the network interface after said first packet (see 
col. 3-4, lines 57-7, the routing device identifies a message flow, the 
packets are compared to determine if is part of a message flow). 

Kerr et al. fails to specifically point out a first indication if said 
first packet is ready for transfer to the host computer; and a second 
indication if said first packet is a control packet as claimed; 
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Davies et al teaches a first indication if said first packet is ready 
for transfer to the host computer (See col 4, lines 8-13, The disabling step 
can include checking if a run length encoded data transfer is pending from 
the host, and if so, delaying disabling of the data transfers from the host to 
the peripheral until a data byte associated with the run length encoded data 
is received by the interface controller, otherwise do not delay, the 
disabling step reads on an indication, and control status flag indicates that 
the data is ready, error free and pending) 

a second indication if said first packet is a control packet( see col. 
3, lines 28-41, method can include after execution of the step of 
transferring a data block, either setting the interface controller to disable 
acknowledgment of receipt of data if a flow control status flag indicates 
pending flow stop, receiving of control packets) 

Therefore it would have been obvious to one with ordinary skill in 
the art at the time the invention was made to combine Kerr et al. invention 
with Davies et al. invention because Davies et al. invention provides 
provide methods and apparatus for reducing the complexity of 
programming on the peripheral side of an IEEE interface (see Davies et al. 
col. 3, lines 10-16). 

Applicants have amended claim 23 to recite, in part, "said first packet containing 
a header conforming to a protocol above TCP, the header decoded by the network 
interface." Support for this limitation can be found, for instance, at page 16, lines 15-18 
and page 25, lines 10-13 of the present application. Applicants respectfully assert that 
neither Kerr nor Willkie teaches or suggests this limitation. For these reasons applicants 
respectfully assert that claim 23 is nonobvious over Kerr in view of Davies. 



IV. Conclusion 

For the reasons mentioned above, applicants respectfully assert that the pending 
claims are in condition for allowance, and a Notice of Allowance is solicited. 

Respectfully submitted, 

/Mark Lauer/ 

Mark Lauer 

Reg. No. 36,578 

Silicon Edge Law Group LLP 

6601 Koll Center Parkway 

Suite 245 

Pleasanton, CA 94566 
Tel: (925)621-2121 
Fax: (925) 621-2125 
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